[% setvar title The Perl 6 Summary for the week ending 20021124 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20021124'></a><h1>The Perl 6 Summary for the week ending 20021124</h1>
<p>And some rough beast, its hour come 'round at last
slouches toward...</p>
<p>And then the scansion goes to pot and I can't make a joke fit. Shame.</p>
<p>Anyhoo, it's time for another episode of the continuing saga of
Perl 6 development. When I say 'saga' I don't mean a long, long poem
of alliterative lines, but a bright, breezy and brisk tale of the bods
in the lists. Well, one week mayb, when we've been quiet...</p>
<p>We start, as usual with the internals list.</p>
<a name='C#/Parrot Status'></a><h2>C#/Parrot Status</h2>
<p>Rhys Weatherley, who has been absent from the internals list lo these
many days popped up again to ask about:</p>
<ul>
<li><a name='Object/class support'></a>Object/class support</li>
<li><a name='Fixed-size integers and/or conversion opcodes'></a>Fixed-size integers and/or conversion opcodes</li>
<li><a name='Embedding of binary extension sections'></a>Embedding of binary extension sections</li>
</ul>
<p>He noted that &quot;Not Done Yet&quot; was an acceptable answer. Which is good,
because, as Leopold T&ouml;tsch pointed out, none of them were done
yet.  Leo also reckoned that a start would be to implement fixed size
integers and conversion ops, and asked for details of what was
wanted. Iacob Alin wondered if the various types would be PMCs
(answer: Only those types which don't easily map to native types.)
Florian Weimer wondered about trapping integer arithmetic. Dan says
these will be handled using Parrots standard exception handling
mechanism (which doesn't actually exist yet, but signs in the wind
suggest we might be getting a Halt and Catch Fire op to raise an exception).</p>
<p><a href='http://groups.google.com/groups?threadm=3DD8CF6D.E831119C@zip.com.au' target='_blank'>groups.google.com</a></p>
<a name='Parrot 0.0.9 status'></a><h2>Parrot 0.0.9 status</h2>
<p>According to Steve Fink: &quot;The basic status is that lots of people,
many of them coincidentally named Leopold T&ouml;tsch, have been fixing
zillions of things and implementing a number of new features. Nearly
everything needed for 0.0.9 has happened, and a lot else besides.&quot;</p>
<p>See his post for details of what's still to be done.</p>
<p>One of the most important items was that the tinderbox (a fleet of
machines that constantly make, test and remake the latest parrot
builds) was a beautiful shade of orange and red, which led to
discussion of what was going on (since most people's home boxen seem to
be making and testing okay...) Various remedies and patches were
tried, but I believe the tinderbox is still mostly the wrong colour.</p>
<p><a href='http://groups.google.com/groups?threadm=20021119074745.GH3637@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021120053310.GI3637@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a></p>
<a name='Unified core.jit'></a><h2>Unified <b><i>core.jit</i></b></h2>
<p>Leopold T&ouml;tsch posted an RFC in which he proposed writing a
universal <b><i>core.jit</i></b> which provides the basic JIT framework and which
delegates the generation of native ops to processor specific
implementations. Daniel Grunblatt liked the basic idea, but thought
there might be a case for creating <b><i>cisc.jit</i></b> and <b><i>risc.jit</i></b> to
avoid piles of <code>#ifdef</code>s. Daniel, Leo and Nicholas Clark then spent a
few posts thrashing out issues to do with parameter naming and other
more or less arcane things.</p>
<p><a href='http://groups.google.com/groups?threadm=3DDA36CD.6010905@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Native Function calls'></a><h2>Native Function calls</h2>
<p>Dan announced that he'd redone the native function call interface and
had added a new op, <code>bnc</code>, which stands for `build native call'. His
post has the details of how it all works (and how to use it). Well,
that's what he said at first, but apparently it's not true. What he's
actually done is altered the <code>dlfunc</code> opcode to behave like <code>bnc</code> he
described. (It's a shame you can't hit <code>s/bnc/dlfunc/</code> in your mailer
and have the world alter every single copy of the mail you just
sent. It would have been useful for some of my previous summaries.)</p>
<p>Brent Dax wondered if this was going to be the new XS or if there was
more coming. Answer: Sort of.</p>
<p>Leo T&ouml;tsch didn't like <b><i>nci.c</i></b>'s string functions, and wondered
too about places where you'd need to pass a pointer to the parrot
interpreter. Dan doesn't like the string functions either, noting that
the code is &quot;evil, crufty [and] embarrassing&quot;, but that it is at least
&quot;well encapsulated, so it can be ripped out, shot, and replaced with
something elegant and fast at some point in the future.&quot; As for parrot
interpreter pointers, Dan reckons that any code that needs to go so
far should install real extension sub PMCs.</p>
<p>Gopal V worried about the type safety (it's an obsession of his
apparently) or rather the complete lack of it, in this interface. Dan,
in a quote of the week post said yup, of course it's totally type
unsafe and he liked it that way, before confessing that he was getting
that `XML feeling. (You know the one--&quot;It seemed like a good idea
until I thought about it&quot;)' and started backpedalling. Gopal V made a
few suggestions, and that's about where we left it.</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f04ba01842ac28c@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f03ba01ed3467cf@' target='_blank'>groups.google.com</a>[63.120.19.221] -- the correction</p>
<a name='Leopold T&ouml;tsch, still the patch monster'></a><h2>Leopold T&ouml;tsch, still the patch monster</h2>
<p>Leo's contributions this week include:</p>
<ul>
<li><a name='Patches to the JIT which give a 370% speedup in mops_p.pasm'></a>Patches to the JIT which give a 370% speedup in <b><i>mops_p.pasm</i></b></li>
<li><a name='Patched strings to try and fix a GC issue.'></a>Patched strings to try and fix a GC issue.</li>
<li><a name='More patches to the JIT to tidy things up'></a>More patches to the JIT to tidy things up</li>
<p>This patch set also added i386 support for JITted floating point,
which apparently makes <b><i>mandel.pasm</i></b> at least 10 times faster.</p>
</ul>
<p>And that's not counting his contributions in other threads. Once
again, I wonder where he finds the time.</p>
<p>Other patches this week from other keyboards that Leo's:</p>
<ul>
<li><a name='Op restarts'></a>Op restarts</li>
<p>Jason Gloudon's patch adds a new control flow flag to <b><i>op.h</i></b>
to mark which ops can cause interpreter restarts. This information can
apparently be used to improved performance in JITted code by removing
the need for unnecessary checks.</p>
<li><a name='Function &lt;=&gt; Data Pointer casts in nci.h'></a>Function &lt;=&gt; Data Pointer casts in <b><i>nci.h</i></b></li>
<p>Josh Wilmes's patch to try and correct warnings on some compilers (and
'outright breakage on tcc'). Steve Fink seemed to like it, and
produced an updated version and Dan suggested that they don't
worry about it too much right now as he was in the process of redoing
<b><i>nci.c</i></b> anyway.</p>
<li><a name='Befunge now supports PerlArray's push/pop'></a>Befunge now supports PerlArray's push/pop</li>
<p>Jerome Quelin is one of the &quot;let's implement a bunch of languages on
Parrot&quot; crew, and his pet language is Befunge. If you don't know about
Befunge, you're lucky, but if you don't want to stay lucky, Google
will probably be depressingly informative. Anyhow, Jerome has now
rewritten his Befunge interpreter to use PerlArray's push and pop
rather than his older, hand crafted Parrot assembler routines. Dan
committed the patch `with the appropriate amount of fear'.</p>
<li><a name='The return of Leon Brocard'></a>The return of Leon Brocard</li>
<p>As regular listeners will know, I try to mention Leon Brocard at least
once a week. This has been tricky of late because Leon had been on
holiday. And when he returned he didn't actually say that much.</p>
<p>This week, he rectified that and offered a couple of patches, and a
minor dilemma. The first simply improves a set of error messages,
making it easier to track a couple or three problems down. However,
his second patch is a little trickier.</p>
<p>The thing is, Leon has implemented another programming language for
Parrot. He'd posted it to the list some time ago (before my time as a
summarizer I think), but it'd got out of sync with the state of the
avian, so this time he offered it as a patch with its own subdirectory
of <b><i>languages</i></b>. &quot;So? What's the problem?&quot; I hear you ask. The problem
is the name of this language, which some people may find offensive. In
a postscript to the patch, Leon suggests that a bit of creative
misspelling may be in order, so I'll go that route:</p>
<p>Last week, Leon Brocard posted a patch implementing a brianfuck
interpreter.</p>
<p>There, that was easy wasn't it?</p>
</ul>
<p>Coo, what a remarkably long section with no associated links.</p>
<a name='Meanwhile, on perl6-language'></a><h1>Meanwhile, on perl6-language</h1>
<p>The `Unifying invocant and topic naming syntax' thread rumbled
on. Adam Lopresto wondered what was wrong with <code>sub bar(;$foo is
given) {...}</code>. Damian wasn't sure and reiterated his suggestion of
<code>sub foo (;$foo = $def_foo) is given($def_foo) {...}</code>, but Larry
really didn't like that (and he's not alone -- Ed.) Larry spun off a
few other suggestions, one of which Damian shot down quite handily,
and one of which, after couple of modifications, he quite liked. Brent
Dax wondered what was wrong with just using <code>$CALLER::_</code> and having
done with it, which led to some muttering that the CALLER should
really be a namespace of last resort for people doing bad and/or
clever things and that using it just to import the caller's topic
seemed like overkill. And on it went for a total of 47 posts this
week. Highlights include: Damian's discussion of why it makes sense to
pass the topic into a function without it appearing on the argument
list illustrated with an example from Class::Contract; Andy Wardley's
almost universally disliked suggestion of using <code>$__</code>, <code>$___</code>,
.... to access callers' topics up the call chain; Allison Randal's
handy restating of the details of what was being discussed; Andy
Wardley also brought up the Law of Demeter and got ignored for his
pains.</p>
<p>I have the feeling we haven't seen the last of this yet, things still
aren't quite resolved.</p>
<p><a href='http://groups.google.com/groups?threadm=200211171603.gAHG3ZfO009744@express.cec.wustl.edu' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DD9E81F.8000408@conway.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021119113811.GC89570@cat.ourshack.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021119203510.GJ7056@shadowed.net' target='_blank'>groups.google.com</a> -- Allison's summary</p>
<p><a href='http://groups.google.com/groups?threadm=20021120092058.GH96234@cat.ourshack.com' target='_blank'>groups.google.com</a> -- Law of Demeter</p>
<a name='The string concatenation operator'></a><h2>The string concatenation operator</h2>
<p>The mammoth operator thread continues on it's merry way with a
slightly morphed subject (It's now <i>called</i> the `string concatenation
operator' thread, but it can't fool me). I think it might be slowing
down though; there were only 31 posts in the thread this week.</p>
<p>Anyhow, Martin D Kealey opened proceedings for the week, talking about
parallel processing. (And people wonder why I find this thread hard to
summarize -- the subject line is almost always inaccurate, and it
always seems to be going off on tangents), and the benefits of
functional and applicative programming languages when compilers need
to notice possible parallelism. Simon Cozens talked about typing of
values (not variables), and reckoned that with reasonably strongly
typed values there seemed to be no reason why <code>+</code> shouldn't be used
for string concatenation. However, Larry reckons that not using <code>+</code>
to concatenate strings was one of the things he got right in Perl
1. He also had some interesting things to say about the Principle of
Least Astonishment.</p>
<p>Dan talked about threading (remember, this thread is about the string
concatenation operator), which led into a discussion of the various
ways of handling threading. Matt Diephouse wondered how to pass a
junction to a function. It turns out to be easy; <code>sub foo ($param
is junction) {...}</code>. But not that easy. The subthread that ensued
ended up talking about what happens when some members in junction
cause exceptions to be thrown when others don't, and I'm <i>still</i> not
sure what's going on.</p>
<p>I don't suppose someone would like to write an article on junctions
along the same lines as Allison's 'Topics' article? Or is it still way
too early to do that?</p>
<p><a href='http://groups.google.com/groups?threadm=E18Elau-0001AS-00@ns0' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021123210520.GA21248@wall.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05200f00b9fdb26fa549@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Continuations'></a><h2>Continuations</h2>
<p>The misnamed coroutines thread continued, discussing the use of
coroutines as iterators in while and for loops, which then morphed
into a discussion of <code>&lt;&lt;</code>. You see, <code>&lt;&lt;...&gt;&gt;</code> is the ASCII
synonym for <code>«...»</code>, which is, in turn a (the?) new
way of saying <code>qw/.../</code> (and for vectorizing an op). Ken Fox worried
that using <code>&lt;&lt;</code> in this way would mean you couldn't use it for
introducing a HERE doc, but Damian assured him that it wasn't a
problem because <code>&quot;</code> (and presumably <code>'</code>) would be illegal as the
very first character of a <code>&lt;&lt;...&gt;&gt;</code> delimited list. This
worried Paul Johnson slightly who paged Simon Cozens (Champion of
Regularity! Smiter of the Unexpected!) who didn't show up.</p>
<p>Austin Hastings asked if we couldn't rename coroutine <code>next</code> to be
<code>bork</code> (standing for &quot;Break OR Kontinue&quot; or &quot;Brain On Raw Krack&quot;, you
decide) just so he could write</p>
<pre>   my $cheffy = $recipe.iterator;
   $cheffy.bork.bork.bork;</pre>
<p>Damian appeared to take him seriously (well, not about the bork thing,
but the post wasn't just about the silliness).</p>
<p>All of which eventually led to Damian's rather sensible proposal on
the semantics of <code>&lt;...&gt;</code>, which is well worth a read. The rest of
the thread was spent with people asking for a few clarifications.</p>
<p>Quote of the Thread:</p>
<pre>   Damian: &quot;Think Of It As Evolution In Action&quot;
   Austin: This coming from someone whose national bird is
       the platypus</pre>
<p>Hey, it made me laugh.</p>
<p><a href='http://groups.google.com/groups?threadm=3DD843FC.1030008@conway.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DD9AE1D.9020303@vulpes.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021118181622.3030.qmail@web12307.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DD9A74C.205@conway.org' target='_blank'>groups.google.com</a> -- semantics of <code>&lt;...&gt;</code></p>
<a name='Superpositions and Laziness'></a><h2>Superpositions and Laziness</h2>
<p>Piers Cawley failed to change the subject line as he asked about
runtime class creation. He wanted to know if one could do:</p>
<pre>    class {
        push @ISA, $parent_class;
        ...
    }</pre>
<p>Damian sincerely hoped not. Frankly, so does Piers, what he really
wants is a nice interface to Class:</p>
<pre>    Class.new( isa =&gt; $class ) {
        method { ... }
        method { ... }
    }</pre>
<p>But so far everybody has ignored that post...</p>
<p><a href='http://groups.google.com/groups?threadm=84of8kd2xk.fsf@despairon.bofh.org' target='_blank'>groups.google.com</a></p>
<a name='Dynamic scoping (take 2)'></a><h2>Dynamic scoping (take 2)</h2>
<p>Ralph Mellor posted a summary of his understanding of dynamic scoping
with <code>temp</code> and <code>let</code> and went on to propose a system of implicit
argument passing, intended to get 'round the perceived problem of
threading and dynamic scope not playing well together. Larry pointed
out that Ralph seemed to have a misapprehension about Perl threads
where, unless a variable is explicitly marked as shared between
threads then dynamically scoped variables work just fine. Larry went
on to discuss some rather splendid extensions of the currying concept:</p>
<pre>   use Dog.assuming(tail =&gt; &quot;cut short&quot;, ears =&gt; &quot;cut_long&quot;)
   my $little_dog = Dog.where_oh_where();</pre>
<p>Which is rather cute.</p>
<p><a href='http://groups.google.com/groups?threadm=0db401c29363$a3d229a0$6601a8c0@ralph' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021125181919.GA10720@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, on the documentation list'></a><h1>Meanwhile, on the documentation list</h1>
<p>The Documentation list continued its mission to explain, spending the
week working on Numeric Literals, producing a 5th summary of what is
known.</p>
<p><a href='http://groups.google.com/groups?threadm=95AB858A-00A0-11D7-9C01-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='In brief'></a><h1>In brief</h1>
<p>Last week, Brent Dax stated that we'd have to write Perl6 in Perl
'because otherwise we can't have the self modifying grammars'. Which
caused Simon Cozens to wonder why he'd been spending so much time
writing self modifying parsers in C.</p>
<p>Joseph F. Ryan has been writing tests for numeric and string literals
and keeping them in sync with discussions on
perl6-documentation. Thanks Joseph.</p>
<p>David Robins wondered when the long double bug would be fixed. Nobody
quite knows, but Dan is working on it, once he gets a compiler back up
on his long double machine.</p>
<a name='Who's Who in Perl 6?'></a><h1>Who's Who in Perl 6?</h1>
<ul>
<li><a name='Who are you?'></a>Who are you?</li>
<p>Nicholas Clark</p>
<li><a name='What do you do for/with Perl 6?'></a>What do you do for/with Perl 6?</li>
<p>Lurk. Sadly I usually generate more e-mail than code. I sometimes dabble in
fixing compiler warnings, the ARM JIT, and anything else that seems
interesting to me. It's a good thing I'm not expected to do anything
important, as parrot would never get finished if were.</p>
<li><a name='Where are you coming from?'></a>Where are you coming from?</li>
<p>Well, porting Perl5 to RISC OS, then getting gradually sucked into being a
core Perl5 porter. I keep seeing things that look fun to implement which
no-one else seems to want to do, so I try to implement them myself.</p>
<li><a name='When do you think Perl 6 will be released?'></a>When do you think Perl 6 will be released?</li>
<p>Before perl 5.10
However, I doubt Perl 6 will be ready by 1st April next year :-(</p>
<p>I believe that the parrot engine will become substantially useful by the
middle of next year. However, I expect that the Perl 6 language design will
not be complete by then, let alone implemented, let alone implemented
optimally. So I suspect that the first real users of the parrot engine will
be &quot;other&quot; languages. It's a shame that many of the major dynamic languages
which could be implemented on top of parrot don't have anywhere near the
level of regression tests that Perl does, as I'm told that this lack of
tests makes it much harder to go about writing a re-implementation.
I blame Schwern for making it too easy for Perl people to write tests :-)</p>
<li><a name='Why are you doing this?'></a>Why are you doing this?</li>
<p>The perl5 internals are a complete mess. It's like Jenga - to get the perl5
tower taller and do something new you select a block somewhere in the middle,
with trepidation pull it out slowly, and then carefully balance it somewhere
new, hoping the whole edifice won't collapse as a result.
The only long term solution to the perl5 internals is a complete re-write,
and far too many corner cases of perl5 (as well as all of XS) actually
depend on how bits of the internals work, so an internals only re-write
isn't going to be possible without some changes at the language level.
And as the language itself has to change, then it might as well progress
too.</p>
<li><a name='You have 5 words. Describe yourself.'></a>You have 5 words. Describe yourself.</li>
<p>incorrigible pragmatic noisy pedantic perfectionist</p>
<li><a name='Do you have anything to declare?'></a>Do you have anything to declare?</li>
<p>I've probably just contradicted myself. It wouldn't be the first time.
On, and I can't code anywhere near as fast as I can talk. Sorry.</p>
</ul>
<a name='Acknowledgements'></a><h1>Acknowledgements</h1>
<p>Proofreading was once again provided by Aspell and myself. I really
should start writing this thing on Mondays again, then I'd have time
to get it properly proofread by other human beings. Ah well. Next
week.</p>
<p>I've been getting some interesting mail recently about Perl 6 and what
it's doing from people who aren't active on the mailing lists, to the
extent that I'm thinking of adding a `letters to the editor' section
(assuming I ever find the time). Is this a good idea? Am I even madder
than you thought I was? What day is this? Are you the nurse? Only they
tell me I'm not supposed to talk to strangers...</p>
<p>Ahem.</p>
<p>Here's the chorus once more:</p>
<p>If you didn't like the summary, what are you doing still reading it?
If you did like it, please consider one or both of the following
options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl 6.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl 6.</li>
<li><a name='Send feedback, flames, money and/or a Nikon Coolscan 4000 ED to mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a> (One of these days, this is going to work...)'></a>Send feedback, flames, money and/or a Nikon Coolscan 4000 ED to
mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a> (One of these days, this is going to
work...)</li>
</ul>
<p>The fee paid for publication of these summaries on perl.com is paid
directly to the Perl Foundation.</p>
</div>
